技術 Day 29：這套方法論的邊界——哪些情境不該套用

前言：「什麼情境都適用」，本身就是一個警訊 如果一套方法論宣稱自己什麼情境都適用，那通常代表它還沒被誠實檢驗過邊界在哪裡。這個系列講了 28 天的 Outsid...

技術 Day 21：讓 AI 自己先跑一次 Outside-In 流程，而不是事後補救

前言：「複雜度預算不就是事後補救嗎？」 昨天講完複雜度預算，可能有讀者已經在心裡吐槽：這套機制還是「等 AI 寫完，我再去檢查改了幾個檔案」，本質上還是事後補救...

技術 Day 18：GOOS 的核心洞察——讓外層測試逼出你真正需要的類別

前言：「這套方法論該不會是你自己發明的吧？」 昨天講完 Outside-In TDD／ATDD 怎麼擋住過度設計，這裡有一個很合理的質疑：這聽起來很像是「先射箭...

技術 Day 17：Outside-In TDD／ATDD——最古老的過度設計解藥

前言：「這系列講了 16 天問題，到底什麼時候要講解法？」 如果你從 Day 1 一路看到這裡，大概已經受夠「過度設計有多可怕」這件事了——745 個檔案、21...

技術 Day 9：版本 A——用 Outside-In TDD／ATDD 寫出來的乾淨版本長怎樣

前言：「業務邏輯這麼簡單，隨便寫都差不多吧？」 看到「新聞發佈系統」這幾個字，你腦中浮現的畫面可能是：一個 Article 資料表、幾個 CRUD API，隨便...

技術 Day 8：案例設計——一個新聞發佈系統，同一組驗收測試，兩種寫法

前言：「這種對照案例，是不是特意做出來嚇人的？」 看到「87 倍行數落差」「92% 死碼」這種數字，很自然會懷疑：這是不是刻意做出一個極端案例，用來製造戲劇效果...